Ollama keep models loaded for longer than 5 minutes idle time

Ollama keeps loaded models for 5 minutes in memory if they are idle.

When you use the API to load a model, you can specify how long it stays in memory by model.
But probably it would be a good idea to change the default time as well.

The setting is controlled via an environment variable.
For a container image you would just pass it as a parameter:

-e "OLLAMA_KEEP_ALIVE=30m"

For Ollama running as a Linux service, you have to add it to the systemd service like this:

/etc/systemd/system/ollama.service

Environment="OLLAMA_KEEP_ALIVE=30m"

The default unit is seconds. You can specify a unit behind the idle shutdown delay (like m for minutes).

I just looked it up set it on my servers.

Ollama loads LLMs automatically if they have been downloaded.
Dynamically loading of LLMs is quite useful. But loading them again after 5 minutes of idle time would delay requests if the LLM as been unloaded.

You can also configure how many models should be loaded at most via OLLAMA_MAX_LOADED_MODELS (the default is 3).
Usually you can't run too many models at the same time. But if you are testing with smaller models, this still might be important:


-- Daniel


Example for some smaller models all loaded into the CPU in parallel:

ollama ps
NAME             ID              SIZE      PROCESSOR    UNTIL
qwen2.5:0.5b     a8b0c5157701    1.3 GB    100% GPU     29 minutes from now
granite3.2:2b    9d79a41f2f75    3.2 GB    100% GPU     29 minutes from now
gemma3:1b        8648f39daa8f    1.9 GB    100% GPU     27 minutes from now

• Comments [0]

Get ready for Domino 14.5 EA3

The final 14.5 EA3 Early Access version is about to be released next week.
We can expect updates in Domino IQ and a couple of other features.
The EAP Forum is the place to get all up to date information and to ask questions --> https://hclsw.co/domino-14-5-eap-forum

I am planning t provide an updated version about the Domino IQ Lab database and to post some examples to help with the new functionality we can expect.

There is also a webinar On Wednesday you should join:

Date: April 23, 2025 Time: 10 AM - 11 AM EDT
Register Now: https://register.gotowebinar.com/register/5527396029191085664

You should really join the webinar and the the forum.

If you are on a Domino 14.5 EA release you can leverage AutoUpdate to update to the latest version automagically on Windows and Linux.

See you in the forum...

• Comments [0]

Creating ACME certificates with Go

"LEGO" is a full featured ACME implementation including DNS-01 challenges.
But if you just need a basic ACME functionality for HTTP-01 requests, there are modules available directly from Go.

"golang.org/x/crypto/acme/autocert" provides an easy to use interface, which works hand in hand with the Go web-server functionality.

The following simple program creates a certificate and starts a simple demo web-server.
This brings ACME directly into your application without any extra tools if you are working with Go.

Reference:
https://pkg.go.dev/golang.org/x/crypto/acme/autocert


package main

import (
  "crypto/tls"
  "log"
  "net/http"
  "os"
  "net"
  "strings"
  "golang.org/x/crypto/acme"
  "golang.org/x/crypto/acme/autocert"
)

func main() {

  szHostname, err := os.Hostname()

  if err != nil {
      log.Println ("Error getting hostname:", err)
      return
  }

  szFQDN, err := net.LookupCNAME(szHostname)

  if (err == nil) {
      szHostname = strings.TrimSuffix (szFQDN, ".");
  }

  log.Println ("Local Hostname: ", szHostname)

  manager := &autocert.Manager{
      Cache:      autocert.DirCache("certs"), // Local cert cache
      Prompt:     autocert.AcceptTOS,
      HostPolicy: autocert.HostWhitelist (szHostname),

      Client: &acme.Client{
          DirectoryURL: "https://acme-staging-v02.api.letsencrypt.org/directory",
      },
  }

  server := &http.Server{
      Addr: ":443",
      TLSConfig: &tls.Config{
          GetCertificate: manager.GetCertificate,
      },
      Handler: http.HandlerFunc (func(w http.ResponseWriter, r *http.Request) {
          w.Write([]byte ("Hello, Staging HTTPS world!"))
      }),
  }

  // Redirect HTTP to HTTPS
  go func() {
      log.Fatal (http.ListenAndServe (":80", manager.HTTPHandler(nil)))
  }()

  log.Println ("Starting HTTPS server with Let's Encrypt staging certs...")
  log.Fatal (server.ListenAndServeTLS("", ""))
}

• Comments [0]

Using a proxy to optimize downloads and packet updates

Proxying downloads can be tricky. If the resouce is HTTPS there isn't easy way because the connection is encrypted.
But for HTTP resources a Squid proxy can cache downloads very effective.

Cache HTTP resource

Linux distributions often use HTTP resources, because the software itself is signed.
This opens the door for effective caching.
I have pointed Linux machine and Docker host to my Squid proxy.
Not only that the cache dramatically reduce the downloaded data on second download.
It also reduces the download time dramatically.
Some hot data might even come from memory as you see in my test below.

Caching should be setup with care. Not everything should be cached for a longer time.
*.deb packages can be safely cached, because the file names would have a different file name when updated.


1745101322.369    485 172.17.0.2 TCP_OFFLINE_HIT/200 42288974 GET http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-lts/openjdk-11-jre-headless_11.0.26%2b4-1ubuntu1%7e24.04_amd64.deb - HIER_NONE/- application/vnd.debian.binary-package
1745101322.370      0 172.17.0.2 TCP_MEM_HIT/200 209690 GET http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-lts/openjdk-11-jre_11.0.26%2b4-1ubuntu1%7e24.04_amd64.deb - HIER_NONE/- application/vnd.debian.binary-package


Cache container images

Container registries mostly use HTTPS. In that case a registry with caching support like the Harbor registry could make sense.


Cache MyHCLSoftware downloads

HCL Software downloads like many other software downloads are HTTPS only.
One of the main reason is that authentication is required.

The Domino Download Server project provides a way to download software, which then can be locally accessed.
A Domino Download Server could be the source for internal downloads, container builds and even the Domino AutoUpdate functionality can leverage the Download Server.


https://github.com/nashcom/domino-startscript/tree/develop/domdownload-server

Conclusion

Now matter how fast your internet connection is, a local download is always faster and reduces resource usage.

• Comments [0]

Let’s Encrypt ACME implementation in GO -- LEGO

Domino CertMgr has full ACME / Let's Encrypt integration. But there might be cases where you need for other servers. I discovered an interesting project when looking for an ACME client for Go. The project offers: A command-line interface Go Libs to use in your own applications A container image Beside HTTP-01 challenges the project supports many DNS-01 integrations with reference to the APIs used. Specially setting up a new environment HTTP-01 challenges are important. Getting a certificate uses a simple command-line, which is also available on Docker. Here is a simple Docker example: docker run --rm \ -v $(pwd)/data:/data \ -p 80:80 \ goacme/lego \ --http \ --domains www.acme.com \ --email info@acme.com \ --accept-tos \ --server https://acme-staging-v02.api.letsencrypt.org/directory \ --path /data \ run It's a well done integration with many options and is easy to use at the same time. This should not replace any of your existing Domino CertMgr flows, but can help you in one or the other case. OK on top the project name is pretty cool. Not sure how they get away with this name.

• Comments [0]

Choosing the Right Desktop Virtualization Solution for Mac and Windows

Here is an experiment. I told ChatGPT what I like to say and just fine tuned the result.
ChatGPT is really helpful meanwhile - If you ask the right questions and returns grat results of all sorts of topics.
The following blog post is co-authored with ChatGPT.

Specially on Windows the world changed a bit. For most people (including me) VMware is not an option any more even it is free for personal use meanwhile.
I was a big fan of Windows Sandbox. But with Windows 11 and other software installed it became quite instable for me.

Even I never liked Hyper-V on the server side, as an easy local solution it plays well with other virtualization built on the same foundation like WSL.
WSL2 is a game changer for me for quite a while -- not only for Docker development. I am working with it every day and it is well integration into the Windows stack both ways.
From Windows to access Linux resources and from Linux to access Windows resources.

I would be interested to hear which VM solutions you use in your environment and why..

Daniel


Introduction

As development environments shift toward containers and platform-agnostic workflows, desktop virtualization remains an essential too l— especially for developers, system administrators, and DevOps engineers.
Whether you're working on macOS or Windows, selecting the right virtualization solution is critical for performance, compatibility, and efficiency.
This post highlights the best options for virtualization on Mac and Windows, with a clear breakdown of commercial and free tools, and a special focus on Apple Silicon Macs and Windows ARM-based systems.


-- Virtualization on macOS ---

Apple’s transition to Apple Silicon has changed how virtualization works.
These systems only support ARM-based operating systems natively, which affects tool compatibility, including some legacy enterprise software.


Best Commercial Option: Parallels Desktop

Parallels remains the most refined, high-performance commercial virtualization tool for macOS.
It supports Windows 11 ARM, various Linux distros, and offers excellent Apple Silicon support with fast boot times and tight macOS integration.


Best Free Option: UTM

UTM is a solid open-source alternative. It uses QEMU under the hood and can run ARM and emulated x86 systems (though x86 emulation is slower). It’s a great option for personal projects or basic dev/testing needs.


Commercial Container Option: Docker Desktop for Mac

Docker Desktop is widely used for container-based development. On Apple Silicon, containers must be ARM-based, and some legacy images may not work without modification.
Docker Desktop is free for small teams but requires a paid subscription for larger organizations (250+ employees or $10M+ in revenue).

Important for Domino users: Domino agents on Linux do not work on Apple Silicon Macs due to the lack of x86 compatibility.


Free Container Option: Rancher Desktop

Rancher Desktop is an open-source alternative to Docker Desktop, supporting Kubernetes and containerd. It’s a great choice for developers who want to avoid licensing fees while still getting a container-native workflow.


--- Virtualization on Windows --

Windows offers a rich set of virtualization and containerization tools—many built-in or easily installed. With support for both x86 and ARM editions of Windows 11, your choice depends on the host hardware and guest OS requirements.


Native VM Option: Hyper-V

Since VMware Workstation is off the table for me, even it is now free but hard to get Hyper-V seems to be the best option.

Hyper-V is Microsoft’s built-in hypervisor for Windows 10 Pro and all versions of Windows 11 with Pro or Enterprise licensing. It supports a wide range of guest OSes and is ideal for more traditional VM workloads.


Note: If you’re running Windows on ARM (like on a Surface Pro X), you’ll need to use Windows 11 ARM Edition for your guest VMs.


Virtualizing Linux on Windows

For developers focused on Linux environments, Windows offers multiple high-performance options that don’t require full VMs.


WSL2 with Ubuntu (Recommended)

WSL2 (Windows Subsystem for Linux v2) with Ubuntu is the best way to run a full Linux environment on Windows. It uses a lightweight VM backend and provides near-native performance. Perfect for dev work, scripting, and server emulation.

• Fast startup
• Deep Windows integration (file system access, network)
• No need for dual-boot or heavy VM management

Docker Desktop with WSL2 Integration

Docker Desktop integrates seamlessly with WSL2, making it easy to run containers inside your Linux subsystem. This hybrid model gives you the best of both worlds: native Docker CLI in Linux with a Windows GUI when needed.

• Preferred by most container-based developers
• Easy setup and Kubernetes support
• Commercial licensing applies to larger organizations

Docker Daemon in WSL2 (Manual Setup)

For power users or those avoiding Docker Desktop licensing, you can install the Docker Engine directly inside a WSL2 instance (e.g., Ubuntu). This gives you full Docker CLI functionality without Docker Desktop.

• Lightweight, manual setup
• Avoids licensing fees
• Ideal for scripting or custom CI/CD environments

Bonus Tip: Docker as a "Mini-VM" with Red Hat UBI

If you're looking for VM-like behavior within containers, check out the Red Hat UBI init image. This image runs systemd and other init services, making it behave much more like a traditional Linux VM.
Perfect for testing services that rely on init behavior or for more complex container orchestration needs.
With the UBI init image, containers feel a lot closer to VMs—great for simulating production-like environments.


Comparison Table

Platform	Virtualization Tool	Type	Notes
Mac	Parallels Desktop	Commercial VM	Best for Apple Silicon
Mac	UTM	Free VM	Great for light use, ARM-based only
Mac	Docker Desktop	Commercial Container	ARM-only; licensing applies
Mac	Rancher Desktop	Free Container	Good for Kubernetes users
Windows	Hyper-V	Free VM	Built-in on Pro/Enterprise
Windows	WSL2 + Ubuntu	Free Linux Env	Best Linux dev experience
Windows	Docker Desktop + WSL2	Commercial Container	Powerful, GUI-based
Windows	Docker Engine in WSL2	Free Container	Lightweight, CLI-focused

Conclusion

Virtualization and containerization have matured into robust, flexible options for Mac and Windows users alike. Just remember:

• On Apple Silicon, you're locked into ARM-compatible guests.
• On Windows ARM, use Windows 11 ARM Edition for VMs.
• For container workloads, Docker + WSL2 (on Windows) and Docker or Rancher (on Mac) offer clean, modular workflows.

-- Links --

macOS Virtualization Tools

Parallels Desktop
https://www.parallels.com/products/desktop/

UTM (Free)
https://mac.getutm.app/

Docker Desktop for Mac (Commercial)
https://www.docker.com/products/docker-desktop/

Rancher Desktop (Free)
https://rancherdesktop.io/


Windows Virtualization Tools

Hyper-V (Built-in)
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-overview

WSL2 (Windows Subsystem for Linux)
https://learn.microsoft.com/en-us/windows/wsl/

Docker Desktop for Windows (Commercial)
https://www.docker.com/products/docker-desktop/

Docker Engine in WSL2 (Free)
https://docs.docker.com/engine/

• Comments [0]

"Go" language is so freaking awesome!

Not all that I do is plain Domino. As you might now I am working on Linux projects which are mostly related to Domino but don't run directly on Domino.

"If you only have a hammer, every problem looks like a nail". If you have a toolbox with the right set of tools, you can choose the right tool for each task.

I wrote a type of setup application in C++ to generate certs, host web resources, process forms and manipulate JSON.

This required OpenSSL and RapidJSON and was quite complex.
I decided to take a look at GO and rewrote the whole project (and more) with like 600 lines of code.

Go is pretty awesome and so easier than C/C++.

OK creating a CA and certificates in the right way isn't easy but still much easier than in C.

• Reading, creating and updating JSON is pretty simple out of the box
• Hosting web resources is just a couple lines of code to how static files
   

I am really impressed about Go. It's well designed and has a lot of functionality that just makes sense.

Go comes with a run-time and can be statically linked.

On Linux you can just use gccgo. It can bundle everything needed to run the application in a single executable.

If I can publish it, there will be also instructions to compile and run on Linux and Windows.

-- Daniel

• Comments [0]

Adding trusted roots to Domino containers

Linux and Domino comes with a good set of public trusted certs.
But in corporate environment you often have to add your own trusted root for a corporate CA.

This starts with Linux which needs certificates to validate repository servers and other resources.

Domino trusted roots

But also within Domino there are trust stores which might need central management.
Domino Directory Trusted roots, certstore.nsf Trusted roots can be easily centrally updated.

But the following two trust stores are more difficult to manage:

• /local/notesdata/cacert.pem used for HTTP Requests in Lotus Script and other backend code using curl
• Domino JVM trust store used by Java

The cacert.pem file could be written by an agent.
But the JVM trusted roots are located in the binary directory, which is write protected.

The following document describes how this functionality works

https://opensource.hcltechsw.com/domino-container/reference_custom_roots/

For feedback please open a GitHub issue in the project instead of comments to this blog post

-- Daniel

• Comments [0]

Domino container custom repositories

Last month I helped customer moving their physical partitioned servers to container based servers.
Instead of having multiple partitions, we they liked my idea of having multiple containers per Linux host instead on new virtual servers.

Building behind a proxy

Building in a corporate environment has a couple of additional challenges.
It usually starts with the requirement for a proxy to have internet access to pull images and updates--> https://opensource.hcltechsw.com/domino-container/howto_proxy/

Custom Linux repositories

But in larger environments a local repository mirror is used. Even some providers like Hetzner are providing local repositories for their customers.
Usually this is implemented by creating an own corporate image, your Domino images is based on.
For Ubuntu 24.04 and Debian 12 the project now contains an out of the box way to specify custom repositories: --> https://opensource.hcltechsw.com/domino-container/reference_custom_mirror/
For Hetzner I added custom repository mirror examples, ready to use when you servers are hosted on Hetzner.

I started to put all the information into the GitHub repository instead of blogging all the details separately.
If you have questions you can raise issues in the project. I thought about enabling discussions in the project.

-- Daniel

• Comments [0]

What you should know about Domino "res" files on Linux and AIX

res files actually come from Windows and are used to translate strings for UI and errors.
Those res files are usually linked to the Windows binary.

Linux and AIX also use "res" files in a res/ directory below the binary directory.

The files are essential for a server. All the core code string resources are in strings.res.
Most Domino native servertasks also use string resources.
C-API SDK applications can also use string resources, but usually use hard coded strings and not need external res files.

• When installing Domino the locale of the root user is used.
• When running Domino the locale of the "notes" user is used.

Those two locales should be the same. If there is a mismatch, no error texts might be displayed.

"en_US.UTF-8" is truncated to "en_US" and then searched on disk.


Special logic for English locales

• There is specific logic in the internal start script to map English to the system locale "C" (you can see the logic copied below)
• The system locale "C" is the "POSIX" locale and is a special case.
• The directory is also the fallback if no locale is found.

But the following logic is only used for English at run-time and install time.
For other languages the full locale de_DE.UTF-8 is used to install the res files.

But it turns out that at run-time only the first 5 chars of the locale (e.g. de_DE) are used to lookup the resource directory.


Potential problems

In case you had other settings for the root/notes user at install time than the previous install, it can happen that you install into for example the de_DE.UTF-8 directory and the run-time uses the "C" directory.

This would cause potentially wrong res files to be loaded.
Using the wrong res files will not have new string resources added in the new version.
In addition it will show the wrong Domino version, because strings.res ordinal 1 is the Domino version.

It took until now to find out about the details and I had to trace the system calls to find out.
This isn't new at all and I had questions from admins about locale issues.

The Domino container project always uses the POSIX locale during installation.
That means the resulting directory is always called "res/C".
But beside adding the full locale the container project now sets the short locale without UTF-8 for English and German.

When you run a Domino native installation outside a container, you should be aware of those details.
A future Domino version might address this in the installer. But today you should be aware of those details.
In case your Domino version is not updated, you might need to check the "res" files.

Here are the details from a trace and the Domino internal start script called instead of the binaries.

I hope this explains how it works and what to look for when you run into a mismatch.

Today's server all uses UTF-8 locales, which causes effects we might not have seen in earlier versions.

I hope this helps to solve one or another ticket.

-- Daniel



Logic in internal start script -- invoked to start all servertasks

if [ -z "$LANG" ]; then
     LLANG="C"
else
     LLANG=$LANG
     case ${LLANG} in
             POSIX   |\
             posix   |\
             en_US*  |\
             En_US*  |\
             en_GB*  |\
             En_GB*  )
             LLANG="C"
             ;;
     esac
fi
export LLANG


Logic in the installer perl script

# if LANG isn't set or we're in English, move to res/C.  Otherwise, use the language name
if (
  (! $ENV{'LANG'}) ||
  ($ENV{'LANG'} =~ /^posix$/i) ||
  ($ENV{'LANG'} =~ /^en_us/i) ||
  ($ENV{'LANG'} =~ /^en_GB/i)
  )
{
  $langpath = "res/C";
}
else
{
  $langpath = "res/$ENV{'LANG'}";
}

--- systrace ---

access("/opt/hcl/domino/notes/latest/linux/res/en_US", R_OK) = -1 ENOENT (No such file or directory)
access("/opt/hcl/domino/notes/latest/linux/res/C", R_OK) = 0
access("/opt/hcl/domino/notes/latest/linux/res/C/strings.res", R_OK) = 0
openat(AT_FDCWD, "/opt/hcl/domino/notes/latest/linux/res/C/strings.res", O_RDONLY) = 3


Here is what we are adding in the container project

C
de_DE -> C
de_DE.UTF-8 -> C
en_US -> C
en_US.UTF-8 -> C

• Comments [0]